And so we're building CDs / DVDs and larger images. Lots of people joining us, either to say Hi or to actually add to the tests.All of the most common CDs / DVDs have been tested. Not too many obvious bugs found in our processes this time and tests are going well.Some of the usual suspects but also some new testers: Hi to bittin who dropped in before the Stockholm release party, to smcv and to highvoltage and to liz and Linux-Fan
Hope all's going well with everyone.

When Julian Andres Klode and I added initial Zstandard compression support to Ubuntu s APT and dpkg in Ubuntu 18.04 LTS we planned getting the changes accepted to Debian quickly and making Ubuntu 18.10 the first release where the new compression could speed up package installations and upgrades. Well, it took slightly longer than that. Since then many other packages have been updated to support zstd compressed packages and read-only compression has been back-ported to the 16.04 Xenial LTS release, too, on Ubuntu s side. In Debian, zstd support is available now in APT, debootstrap and reprepro (thanks Dimitri!). It is still under review for inclusion in Debian s dpkg (BTS bug 892664). Given that there is sufficient archive-wide support for zstd, Ubuntu is switching to zstd compressed packages in Ubuntu 21.10, the current development release. Please welcome hello/2.10-2ubuntu3, the first zstd-compressed Ubuntu package that will be followed by many other built with dpkg (>= 1.20.9ubuntu2), and enjoy the speed!

LTS This is my fourth month of working for LTS. I was assigned 12 hrs and worked all of them.

Released DLAs

1. DLA 2672-1 imagemagick_6.9.7.4+dfsg-11+deb9u13
   • CVE-2020-27751 A flaw was found in MagickCore/quantum-export.c. An attacker who submits a crafted file that is processed by ImageMagick could trigger undefined behavior in the form of values outside the range of type unsigned long long as well as a shift exponent that is too large for 64-bit type. This would most likely lead to an impact to application availability, but could potentially cause other problems related to undefined behavior.
   • CVE-2021-20243 A flaw was found in MagickCore/resize.c. An attacker who submits a crafted file that is processed by ImageMagick could trigger undefined behavior in the form of math division by zero.
   • CVE-2021-20245 A flaw was found in coders/webp.c. An attacker who submits a crafted file that is processed by ImageMagick could trigger undefined behavior in the form of math division by zero.
   • CVE-2021-20309 A division by zero in WaveImage() of MagickCore/visual-effects.c may trigger undefined behavior via a crafted image file submitted to an application using ImageMagick.
   • CVE-2021-20312 An integer overflow in WriteTHUMBNAILImage of coders/thumbnail.c may trigger undefined behavior via a crafted image file that is submitted by an attacker and processed by an application using ImageMagick.
   • CVE-2021-20313 A potential cipher leak when the calculate signatures in TransformSignature is possible.
2. DLA 2677-1 libwebp_0.5.2-1+deb9u1
   • CVE-2018-25009 An out-of-bounds read was found in function WebPMuxCreateInternal. The highest threat from this vulnerability is to data confidentiality and to the service availability.
   • CVE-2018-25010 An out-of-bounds read was found in function ApplyFilter. The highest threat from this vulnerability is to data confidentiality and to the service availability.
   • CVE-2018-25011 A heap-based buffer overflow was found in PutLE16(). The highest threat from this vulnerability is to data confidentiality and integrity as well as system availability.
   • CVE-2018-25012 An out-of-bounds read was found in function WebPMuxCreateInternal. The highest threat from this vulnerability is to data confidentiality and to the service availability.
   • CVE-2018-25013 An out-of-bounds read was found in function ShiftBytes. The highest threat from this vulnerability is to data confidentiality and to the service availability.
   • CVE-2018-25014 An unitialized variable is used in function ReadSymbol. The highest threat from this vulnerability is to data confidentiality and integrity as well as system availability.
   • CVE-2020-36328 A heap-based buffer overflow in function WebPDecodeRGBInto is possible due to an invalid check for buffer size. The highest threat from this vulnerability is to data confidentiality and integrity as well as system availability.
   • CVE-2020-36329 A use-after-free was found due to a thread being killed too early. The highest threat from this vulnerability is to data confidentiality and integrity as well as system availability.
   • CVE-2020-36330 An out-of-bounds read was found in function ChunkVerifyAndAssign. The highest threat from this vulnerability is to data confidentiality and to the service availability.
   • CVE-2020-36331 An out-of-bounds read was found in function ChunkAssignData. The highest threat from this vulnerability is to data confidentiality and to the service availability.
   CVE-2020-36332 was marked as ignored for stretch due to too disruptive patch for older versions of libwebp.
3. DLA-2687-1 prosody_0.9.12-2+deb9u3
   • CVE-2021-32917 The proxy65 component allows open access by default, even if neither of the users has an XMPP account on the local server, allowing unrestricted use of the server s bandwidth.
   • CVE-2021-32921 Authentication module does not use a constant-time algorithm for comparing certain secret strings when running under Lua 5.2 or later. This can potentially be used in a timing attack to reveal the contents of secret strings to an attacker.
4. DLA-2687-2 prosody_0.9.12-2+deb9u4 Upload prosody_0.9.12-2+deb9u3 introduced a regression in the mod_auth_internal_hashed module. Big thanks to Andre Bianchi for the reporting an issue and for testing the update. CVE-2021-32918, CVE-2021-32920, were marked as ignored for stretch: the affected code is not existing in that version of prosody.

LTS-Meeting I attended the Debian LTS team Jitsi-meeting.

Debian Science Team

openpiv-python I started to package python-openpiv. The software implements PIV (Particle Image Velocimetry) method to compare two images and obtain velocity field.

Other FLOSS activities

Admesh Admesh is the first package which I adopted over 10 years ago! Upstream is not active for a very long time, so I created a github-repo back in 2013. The software helps to manipulate STL-files. STL is the file format for meshes, mostly developed for CAD programs. This month I decided to clean the build system. It was switched to cmake. CI was updated, now it compiles the sources under Linux/Windows environment, runs tests, AddressSanitizer and UndefinedBehaviourSanitizer were employed. Work is ongoing.

MIT Technology Review has an interesting article about Google Project Zero shutting down a western intelligence operation [1]. There s an Internet trend of people eating rotten meat they call high meat (rotten meat) [2]. This is up there with people setting themselves on fire and nut shot videos. A young female who was making popular Twitter posts about motorbikes turned out to be a 50yo man using deep fake technology [3]. He has long hair IRL and just needed to replace his face. After coming out of the closet he has continued making such videos and remains popular. FYHTECH has an informative blog post about using sgdisk to backup and restore GPT partition tables [4]. This is in the Debian package gdisk along with several other tools for managing partition tables. One interesting thing to note is that you can backup a partition table and restore to a smaller device (with a bunch of warnings that you can ignore if you know what you are doing). This is the only way I ve discovered to cleanly truncate a GPT partitioned disk, which is sometimes necessary when running VMs. Insightful blog post about PCIe bifurcation and how PCIe lanes are assigned to sockets [5]. This explains why many motherboards have sockets with unused PCIe lanes, EG *8 sockets that are wired for *4. The PCIe slots all go back to the CPU which has a limited number of *16 PCIe connections that are bifurcated to make the larger number of PCIe slots on the motherboard. New Republic has an interesting article on the infamous transphobe Jordan Peterson s battle with tranquiliser dependency [6]. Wired has an interesting article about the hack of RSA infrastructure related to the SecureID keys 10 years ago [7]. Apparently some 10 year NDAs had delayed it. There are many posts about the situation with Freenode, I think that this one best captures the problems in the shortest amount of text [8]. You could spend a few hours reading about it as I have just done, but just reading this gives you the basics that you need to know to avoid Freenode. That blog post has links to articles about Andrew Lee s involvement with Mt Gox and claims to be the heir to the throne of Korea (which is not a monarchy). Nicholas Wade wrote an insightful and informative article about the origin of Covid19, which leads to the conclusion that it was made in a Chinese laboratory [9]. I first saw this in David Brin s Facebook feed. I would be hesitant to share this sort of thing if it wasn t reviewed by a reliable source, I think David Brin has the skill to analyse this sort of article and the contacts to allow him to seek verification of any scientific issues that are outside his field. I believe that this article is reliable and it s conclusion is most likely to be correct. Interesting Wired article about an art project using display computers at Apple stores to photograph people [10]. Ends with a visit from the FBI.

• [1] https://tinyurl.com/yhoxy6lf
• [2] https://tinyurl.com/ydtssdtx
• [3] https://tinyurl.com/ygwwyrww
• [4] https://tech.feedyourhead.at/content/copy-partition-table-one-disk-another
• [5] https://tinyurl.com/yzf2kw4y
• [6] https://newrepublic.com/article/156829/happened-jordan-peterson
• [7] https://tinyurl.com/yfydxb9r
• [8] https://tinyurl.com/ydl9lajf
• [9] https://tinyurl.com/ygfhdjj9
• [10] https://www.wired.com/2012/07/people-staring-at-computers/

This is an edited copy of an email I sent to provide guidance to users of apt-key as to how to handle things in a post apt-key world. The manual page already provides all you need to know for replacing apt-key add usage:

Note: Instead of using this command a keyring should be placed directly in the /etc/apt/trusted.gpg.d/ directory with a descriptive name and either gpg or asc as file extension

So it s kind of surprising people need step by step instructions for how to copy/download a file into a directory. I ll also discuss the alternative security snakeoil approach with signed-by that s become popular. Maybe we should not have added signed-by, people seem to forget that debs still run maintainer scripts as root. Aside from this email, Debian users should look into extrepo, which manages curated external repositories for you.

Direct translation Assume you currently have:

wget -qO- https://myrepo.example/myrepo.asc   sudo apt-key add  

To translate this directly for bionic and newer, you can use:

sudo wget -qO /etc/apt/trusted.gpg.d/myrepo.asc https://myrepo.example/myrepo.asc

or to avoid downloading as root:

wget -qO-  https://myrepo.example/myrepo.asc   sudo tee -a /etc/apt/trusted.gpg.d/myrepo.asc

Older (and all) releases only support unarmored files with an extension .gpg. If you care about them, provide one, and use

sudo wget -qO /etc/apt/trusted.gpg.d/myrepo.gpg https://myrepo.example/myrepo.gpg

Some people will tell you to download the .asc and pipe it to gpg --dearmor, but gpg might not be installed, so really, just offer a .gpg one instead that is supported on all systems. wget might not be available everywhere so you can use apt-helper:

sudo /usr/lib/apt/apt-helper download-file https://myrepo.example/myrepo.asc /etc/apt/trusted.gpg.d/myrepo.asc

or, to avoid downloading as root:

/usr/lib/apt/apt-helper download-file https://myrepo.example/myrepo.asc /tmp/myrepo.asc && sudo mv /tmp/myrepo.asc /etc/apt/trusted.gpg.d

Pretending to be safer by using signed-by People say it s good practice to not use trusted.gpg.d and install the file elsewhere and then refer to it from the sources.list entry by using signed-by=<path to the file>. So this looks a lot safer, because now your key can t sign other unrelated repositories. In practice, security increase is minimal, since package maintainer scripts run as root anyway. But I guess it s better for publicity :) As an example, here are the instructions to install signal-desktop from signal.org. As mentioned, gpg --dearmor use in there is not a good idea, and I d personally not tell people to modify /usr as it s supposed to be managed by the package manager, but we don t have an /etc/apt/keyrings or similar at the moment; it s fine though if the keyring is installed by the package. You can also just add the file there as a starting point, and then install a keyring package overriding it (pretend there is a signal-desktop-keyring package below that would override the .gpg we added).

# NOTE: These instructions only work for 64 bit Debian-based
# Linux distributions such as Ubuntu, Mint etc.
# 1. Install our official public software signing key
wget -O- https://updates.signal.org/desktop/apt/keys.asc   gpg --dearmor > signal-desktop-keyring.gpg
cat signal-desktop-keyring.gpg   sudo tee -a /usr/share/keyrings/signal-desktop-keyring.gpg > /dev/null
# 2. Add our repository to your list of repositories
echo 'deb [arch=amd64 signed-by=/usr/share/keyrings/signal-desktop-keyring.gpg] https://updates.signal.org/desktop/apt xenial main'  \
  sudo tee -a /etc/apt/sources.list.d/signal-xenial.list
# 3. Update your package database and install signal
sudo apt update && sudo apt install signal-desktop

I do wonder why they do wget gpg --dearmor, pipe that into the file and then cat sudo tee it, instead of having that all in one pipeline. Maybe they want nicer progress reporting.

Scenario-specific guidance We have three scenarios: For system image building, shipping the key in /etc/apt/trusted.gpg.d seems reasonable to me; you are the vendor sort of, so it can be globally trusted. Chrome-style debs and repository config debs: If you ship a deb, embedding the sources.list.d snippet (calling it $myrepo.list) and shipping a $myrepo.gpg in /usr/share/keyrings is the best approach. Whether you ship that in product debs aka vscode/chromium or provide a repository configuration deb (let s call it myrepo-repo.deb) and then tell people to run apt update followed by apt install <package inside the repo> depends on how many packages are in the repo, I guess. Manual instructions (signal style): The third case, where you tell people to run wget themselves, I find tricky. As we see in signal, just stuffing keyring files into /usr/share/keyrings is popular, despite /usr supposed to be managed by the package manager. We don t have another dir inside /etc (or /usr/local), so it s hard to suggest something else. There s no significant benefit from actually using signed-by, so it s kind of extra work for little gain, though.

Addendum: Future work This part is new, just for this blog post. Let s look at upcoming changes and how they make things easier.

Bundled .sources files Assuming I get my merge request merged, the next version of APT (2.4/2.3.something) will do away with all the complexity and allow you to embed the key directly into a deb822 .sources file (which have been available for some time now):

Types: deb
URIs: https://myrepo.example/ https://myotherrepo.example/
Suites: stable not-so-stable
Components: main
Signed-By:
 -----BEGIN PGP PUBLIC KEY BLOCK-----
 .
 mDMEYCQjIxYJKwYBBAHaRw8BAQdAD/P5Nvvnvk66SxBBHDbhRml9ORg1WV5CvzKY
 CuMfoIS0BmFiY2RlZoiQBBMWCgA4FiEErCIG1VhKWMWo2yfAREZd5NfO31cFAmAk
 IyMCGyMFCwkIBwMFFQoJCAsFFgIDAQACHgECF4AACgkQREZd5NfO31fbOwD6ArzS
 dM0Dkd5h2Ujy1b6KcAaVW9FOa5UNfJ9FFBtjLQEBAJ7UyWD3dZzhvlaAwunsk7DG
 3bHcln8DMpIJVXht78sL
 =IE0r
 -----END PGP PUBLIC KEY BLOCK-----

Then you can just provide a .sources files to users, they place it into sources.list.d, and everything magically works Probably adding a nice apt add-source command for it I guess. Well, python-apt s aptsources package still does not support deb822 sources, and never will, we ll need an aptsources2 for that for backwards-compatibility reasons, and then port software-properties and other users to it.

OpenPGP vs aptsign We do have a better, tighter replacement for gpg in the works which uses Ed25519 keys to sign Release files. It s temporarily named aptsign, but it s a generic signer for single-section deb822 files, similar to signify/minisign.

• Reference implementation: https://salsa.debian.org/apt-team/python-aptsign
• Specification: https://wiki.debian.org/Teams/Apt/Spec/AptSign

We believe that this solves the security nightmare that our OpenPGP integration is while reducing complexity at the same time. Keys are much shorter, so the bundled sources file above will look much nicer.

Review: The Magician's Nephew, by C.S. Lewis

Illustrator:	Pauline Baynes
Series:	Chronicles of Narnia #6
Publisher:	Collier Books
Copyright:	1955
Printing:	1978
ISBN:	0-02-044230-0
Format:	Mass market
Pages:	186

The Magician's Nephew is the sixth book of the Chronicles of Narnia in the original publication order, but it's a prequel, set fifty years before The Lion, the Witch and the Wardrobe. It's therefore put first in the new reading order. I have always loved world-building and continuities and, as a comics book reader (Marvel primarily), developed a deep enjoyment of filling in the pieces and reconstructing histories from later stories. It's no wonder that I love reading The Magician's Nephew after The Lion, the Witch and the Wardrobe. The experience of fleshing out backstory with detail and specifics makes me happy. If that's also you, I recommend the order in which I'm reading these books. Reading this one first is defensible, though. One of the strongest arguments for doing so is that it's a much stronger, tighter, and better-told story than The Lion, the Witch and the Wardrobe, and therefore might start the series off on a better foot for you. It stands alone well; you don't need to know any of the later events to enjoy this, although you will miss the significance of a few things like the lamp post and you don't get the full introduction to Aslan. The Magician's Nephew is the story of Polly Plummer, her new neighbor Digory Kirke, and his Uncle Andrew, who fancies himself a magician. At the start of the book, Digory's mother is bed-ridden and dying and Digory is miserable, which is the impetus for a friendship with Polly. The two decide to explore the crawl space of the row houses in which they live, seeing if they can get into the empty house past Digory's. They don't calculate the distances correctly and end up in Uncle Andrew's workroom, where Digory was forbidden to go. Uncle Andrew sees this as a golden opportunity to use them for an experiment in travel to other worlds. MAJOR SPOILERS BELOW. The Magician's Nephew, like the best of the Narnia books, does not drag its feet getting started. It takes a mere 30 pages to introduce all of the characters, establish a friendship, introduce us to a villain, and get both of the kids into another world. When Lewis is at his best, he has an economy of storytelling and a grasp of pacing that I wish was more common. It's also stuffed to the brim with ideas, one of the best of which is the Wood Between the Worlds. Uncle Andrew has crafted pairs of magic rings, yellow and green, and tricks Polly into touching one of the yellow ones, causing her to vanish from our world. He then uses her plight to coerce Digory into going after her, carrying two green rings that he thinks will bring people back into our world, and not incidentally also observing that world and returning to tell Uncle Andrew what it's like. But the world is more complicated than he thinks it is, and the place where the children find themselves is an eerie and incredibly peaceful wood, full of grass and trees but apparently no other living thing, and sprinkled with pools of water. This was my first encounter with the idea of a world that connects other worlds, and it remains the most memorable one for me. I love everything about the Wood: the simplicity of it, the calm that seems in part to be a defense against intrusion, the hidden danger that one might lose one's way and confuse the ponds for each other, and even the way that it tends to make one lose track of why one is there or what one is trying to accomplish. That quiet forest filled with pools is still an image I use for infinite creativity and potential. It's quiet and nonthreatening, but not entirely inviting either; it's magnificently neutral, letting each person bring what they wish to it. One of the minor plot points of this book is that Uncle Andrew is wrong about the rings because he's wrong about the worlds. There aren't just two worlds; there are an infinite number, with the Wood as a nexus, and our reality is neither the center nor one of an important pair. The rings are directional, but relative to the Wood, not our world. The kids, who are forced to experiment and who have open minds, figure this out quickly, but Uncle Andrew never shifts his perspective. This isn't important to the story, but I've always thought it was a nice touch of world-building. Where this story is heading, of course, is the creation of Narnia and the beginning of all of the stories told in the rest of the series. But before that, the kids's first trip out of the Wood is to one of the best worlds of children's fantasy: Charn. If the Wood is my mental image of a world nexus, Charn will forever be my image of a dying world: black sky, swollen red sun, and endless abandoned and crumbling buildings as far as the eye can see, full of tired silences and eerie noises. And, of course, the hall of statues, with one of the most memorable descriptions of history and empire I've ever read (if you ignore the racialized description):

All of the faces they could see were certainly nice. Both the men and women looked kind and wise, and they seemed to come of a handsome race. But after the children had gone a few steps down the room they came to faces that looked a little different. These were very solemn faces. You felt you would have to mind your P's and Q's, if you ever met living people who looked like that. When they had gone a little farther, they found themselves among faces they didn't like: this was about the middle of the room. The faces here looked very strong and proud and happy, but they looked cruel. A little further on, they looked crueller. Further on again, they were still cruel but they no longer looked happy. They were even despairing faces: as if the people they belonged to had done dreadful things and also suffered dreadful things.

The last statue is of a fierce, proud woman that Digory finds strikingly beautiful. (Lewis notes in an aside that Polly always said she never found anything specially beautiful about her. Here, as in The Silver Chair, the girl is the sensible one and things would have gone better if the boy had listened to her, a theme that I find immensely frustrating because Susan was the sensible one in the first two books of the series but then Lewis threw that away.) There is a bell in the middle of this hall, and the pillar that holds that bell has an inscription on it that I think every kid who grew up on Narnia knows by heart.

Make your choice, adventurous Stranger;
Strike the bell and bide the danger,
Or wonder, till it drives you mad,
What would have followed if you had.

Polly has no intention of striking the bell, but Digory fights her and does it anyway, waking Jadis from where she sat as the final statue in the hall and setting off one of the greatest reimaginings of a villain in children's literature. Jadis will, of course, become the White Witch who holds Narnia in endless winter some thousand Narnian years later. But the White Witch was a mediocre villain at best, the sort of obvious and cruel villain common in short fairy tales where the author isn't interested in doing much characterization. She exists to be evil, do bad things, and be defeated. She has a few good moments in conflict with Aslan, but that's about it. Jadis in this book is another matter entirely: proud, brilliant, dangerous, and creative. The death of everything on Charn was Jadis's doing: an intentional spell, used to claim a victory of sorts from the jaws of defeat by her sister in a civil war. (I find it fascinating that Lewis puts aside his normally sexist roles here.) Despite the best attempts of the kids to lose her both in Charn and in the Wood (which is inimical to her, in another nice bit of world-building), she manages to get back to England with them. The result is a remarkably good bit of villain characterization. Jadis is totally out of her element, used to a world-spanning empire run with magic and (from what hints we get) vaguely medieval technology. Her plan to take over their local country and eventually the world should be absurd and is played somewhat for laughs. Her magic, which is her great weapon, doesn't even work in England. But Jadis learns at a speed that the reader can watch. She's observant, she pays attention to things that don't fit her expectations, she changes plans, and she moves with predatory speed. Within a few hours in London she's stolen jewels and a horse and carriage, and the local police seem entirely overmatched. There's no way that one person without magic should be a real danger to England around the turn of the 20th century, but by the time the kids manage to pull her back into the Wood, you're not entirely sure England would have been safe. A chaotic confrontation, plus the ability of the rings to work their magic through transitive human contact, ends up with the kids, Uncle Andrew, Jadis, a taxicab driver and his horse all transported through the Wood to a new world. In this case, literally a new world: Narnia at the point of its creation. Here again, Lewis translates Christian myth, in this case the Genesis creation story, into a more vivid and in many ways more beautiful story than the original. Aslan singing the world into existence is an incredible image, as is the newly-created world so bursting with life that even things that normally could not grow will do so. (Which, of course, is why there is a lamp post burning in the middle of the western forest of Narnia for the Pevensie kids to find later.) I think my favorite part is the creation of the stars, but the whole sequence is great. There's also an insightful bit of human psychology. Uncle Andrew can't believe that a lion is singing, so he convinces himself that Aslan is not singing, and thus prevents himself from making any sense of the talking animals later.

Now the trouble about trying to make yourself stupider than you really are is that you very often succeed.

As with a lot in Lewis, he probably meant this as a statement about faith, but it generalizes well beyond the religious context. What disappointed me about the creation story, though, is the animals. I didn't notice this as a kid, but this re-read has sensitized me to how Lewis consistently treats the talking animals as less than humans even though he celebrates them. That happens here too: the newly-created, newly-awakened animals are curious and excited but kind of dim. Some of this is an attempt to show that they're young and are just starting to learn, but it also seems to be an excuse for Aslan to set up a human king and queen over them instead of teaching them directly how to deal with the threat of Jadis who the children inadvertently introduced into the world. The other thing I dislike about The Magician's Nephew is that the climax is unnecessarily cruel. Once Digory realizes the properties of the newly-created world, he hopes to find a way to use that to heal his mother. Aslan points out that he is responsible for Jadis entering the world and instead sends him on a mission to obtain a fruit that, when planted, will ward Narnia against her for many years. The same fruit would heal his mother, and he has to choose Narnia over her. (It's a fairly explicit parallel to the Garden of Eden, except in this case Digory passes.) Aslan, in the end, gives Digory the fruit of the tree that grows, which is still sufficient to heal his mother, but this sequence made me angry when re-reading it. Aslan knew all along that what Digory is doing will let him heal his mother as well, but hides this from him to make it more of a test. It's cruel and mean; Aslan could have promised to heal Digory's mother and then seen if he would help Narnia without getting anything in return other than atoning for his error, but I suppose that was too transactional for Lewis's theology or something. Meh. But, despite that, the only reason why this is not the best Narnia book is because The Voyage of the Dawn Treader is the only Narnia book that also nails the ending. The Magician's Nephew, up through Charn, Jadis's rampage through London, and the initial creation of Narnia, is fully as good, perhaps better. It sags a bit at the end, partly because it tries to hard to make the Narnian animals humorous and partly because of the unnecessary emotional torture of Digory. But this still holds up as the second-best Narnia book, and one I thoroughly enjoyed re-reading. If anything, Jadis and Charn are even better than I remembered. Followed by the last book of the series, the somewhat notorious The Last Battle. Rating: 9 out of 10

And that's it for another release. A few bugs but nothing show-stopping.Thanks again to Sledge, RattusRattus and Isy, to Linux-Fan and schweer.As the testing page notes, there's a bug in some arm64 installs - the fix should come out via debian-security shortly but you might want to be aware of this. Here's to the next one: only a short time until Bullseye

Linux-Fan and Schweer have just left us: Schweer has confirmed that all the Debian-Edu images are fine and working to his satisfaction. After a short break for food, we're all back in on testing: the Cambridge folks are working hard. There have been questions on IRC about the release in Libera.Chat as well. Always good to do this: at some point in the next couple of months, we'll be doing this for Debian 11 [Bullseye] :)Thanks as ever to all behind the scenes making each point release happen and to those folks supporting LTS and ELTS. It takes a huge amount of bug fixing, sometimes on the fly as issues are discovered, to make it work this seamlessly.

This came up in an install that I was just doing for Debian 10.10 media testing. I hadn't seen this before and it would be disconcerting to other people, though it is a known bug, I think. I was installing an image that had no network and no firmware. KDE failed to run and dropped me to a text mode prompt. This was because the Zotac SBC I'm using requires Radeon R600 firmware to work. There was a warning message on screen to that effect.
The way round this was to plug in a network cable and edit /etc/apt/sources.list. Editing /etc/apt/sources.list was to add contrib and non-free to the appropriate lines to allow me to install firmware-linux-nonfree and firmware-misc-nonfree which includes the appropriate AMD firmware for the embedded Radeon chipset.
Since the machine hadn't been connected to a network at install time, I also needed to run a dhclient command to obtain a network lease and allow me to install the non-free metapackages over the network.Result: success: a full KDE desktop. [The machine is an old Zotac SBC with embedded graphics hardware: AMD E350 - specifically, it requires firmware-amd-graphics and amd64-microcode].

Late blogging on this one.Even as we wait for the final release of Bullseye [Debian 11], we're still producing updates for Debian 10 [Buster].Today has thrown up a few problems: working with Steve, RattusRattus and Isy in Cambridge, Schweer and Linux-Fan somewhere else in the world.A couple of build problems have meant that we've started later than we otherwise might have been and a couple of image runs have had to be redone. We're there now and happily running tests.As ever, it's good to be doing this. With practice, I can now repeat mistakes with 100% reliability and in shorter time :)More updates later.

Focus This month I didn't have any particular focus. I just worked on issues in my info bubble.

Changes

• libpst: header validity check improvement
• iotop: fix getting syscall numbers
• purple-discord: fix line endings
• ptp-gadget: fix typo, https
• wayback-machine-downloader: fix typos, https, JSON output, gitignore, URL creation, API parsing
• duck: indicator phrases
• check-all-the-things: verbosity variation for yamllint, chktex, rubocop, podchecker
• Debian package uploads: purple-discord, sptag
• Debian wiki pages: AdditionalDebianMailingLists, BSP/2021/05/online, DebianHosting, DebianInstaller/Qemu, DebianKeyring, DebianLocations, DebianSpamAssassin, DebianWiki (EditorGuide, MaintenanceTools, ObsoleteText), Derivatives/Guidelines, DeveloperNews, Dovecot, GraphicsCard, Hardware/Wanted, HowToIdentifyADevice/PCI, initramfs, IRC, LoongArch, LunaJernberg, MemberBenefits, PaulWise, PipeWire, Ports, (ia64, loongarch64), PortsDocs/New, PortTemplate, Redmine, RISC-V, sbuild, Seamonkey, systemd, Teams (DebianMaintainerKeyringTeam, Outreach)
• FOSSjobs wiki pages: Resources
• Wikipedia: Asahi (1 2), Message-ID

Issues

• Crash in purple-discord
• Missing source in Open-Sauce-Fonts
• Building at install time in purple-discord
• Memory leak in purple-discord
• AppArmor denials in clamav-freshclam
• Features in diffoscope, trash-cli
• New versions of ddccontrol
• Build failures when using ognibuild: iotop cmake-hello-world
• Broken watch file for hexedit
• Packaging intended for esprima-python
• Unused deps in sptag
• Incorrect build dir in sptag
• Incorrect docs in sptag
• Large git-lfs data in sptag
• Test problems in sptag (1 2), hexedit

Review

• Spam: reported 1 LWN comment, 26 Debian bug reports and 124 Debian mailing list posts
• Debian wiki: RecentChanges for the month
• Debian BTS usertags: changes for the month
• Debian screenshots:
  • approved e2fsprogs sane util-linux wlogout esekeyd ext4magic lxqt xfce4-clipman
  • rejected netselect (random Android app)

Administration

• Debian wiki: unblock IP addresses, approve accounts

Communication

• Joined the great IRC migration
• Respond to queries from Debian users and contributors on the mailing lists and IRC

Sponsors The purple-discord, sptag and esprima-python work was sponsored by my employer. All other work was done on a volunteer basis.

Here's my monthly update covering what I have been doing in the free software world for May 2021 (previous month):

• Opened a pull request to make the build reproducible in the apispec API specification generator. The issue at hand is that the copyright message in the generated documentation used the current build date so that the build would vary depending on whenever you built it. [...]
• Updated my Tickle Me Email tool that implements Gettings Things Done-like behaviours in any IMAP inbox in order to sort various items by the date, not by their subject field. [...]

• As part of my role of being the assistant Secretary of the Open Source Initiative and a board director of Software in the Public Interest, I attended their respective usual monthly meetings. As I outlined last month, my term on the OSI board has been slightly extended due to the discovery of a vulnerability in OSI's recent election as a result, the 2021 election will be re-run to ensure transparency of the process. SPI had their virtual 'face to face' meeting this month as well, spread out over three evenings.

Reproducible Builds The motivation behind the Reproducible Builds effort is to ensure no flaws have been introduced during this compilation process by promising identical results are always generated from a given source, thus allowing multiple third-parties to come to a consensus on whether a build was compromised.

• Kept isdebianreproducibleyet.com up to date. [...]
• Categorised a large number of packages and issues in the Reproducible Builds notes.git" repository.
• Filed an upstream pull request to make the build reproducible in the apispec specification generator. This was also filed in Debian as bug #988978. [...]
• Filed a bug against the Debian jenkins.debian.org virtual packages to report that the reproducible rescheduling CGI script uses the deprecated Debian SSO service. (#989088)
• Drafted, published and publicised our monthly report for April 2021.
• I also made the following changes to strip-nondeterminism, our tool to remove specific non-deterministic results from a completed build:
  • Added support for Python pyzip files: they require special handling to not mangle the UNIX shebang. (#18)
  • Dropped single-debian-patch, etc. from the Debian source package options. [...]

I also made the following changes to diffoscope, including preparing and uploading versions 174, 175 and 176 to Debian:

• Bug fixes:
  • Check that we are parsing an actual Debian .buildinfo file, not just a file with that particular extension after all, it could be any file. (#254, #987994)
  • Support signed .buildinfo files again. It appears that some versions of file(1) reports them as PGP signed message. [...]
  • Use the actual filesystem path name (instead of diffoscope's concept of the source archive name) in order to correct filename filtering when an APK file has been extracted from a container format. In particular, we need to filter the auto-incremented 1.apk instead of original-name.pk. (#255)
• New features:
  • Update ffmpeg tests to work with version 4.4. (#258)
  • Correct grammar in a fsimage.py debug message. [...]
• Misc:
  • Don't unnecessarily call os.path.basename twice in the APK comparator. [...]
  • Added instructions on how to install diffoscope on openSUSE on the diffoscope website [...].
  • Add a comment about stripping filenames. [...]
  • Corrected a reference to site.salsa_url which was breaking the "File a new issue" link on the website [...].

Debian

• python-django:
  • 2.2.21-1 New upstream security release.
  • 2.2.22-1 Another new upstream security release.
  • 2.2.23-1 New upstream release.
  • 3.2.1-1 (to experimental) New upstream security release.
  • 3.2.2-1 (to experimental) Another new upstream security release.
  • 3.2.3-1 (to experimental) New upstream release.
• redis:
  • 6.0.13-1 New upstream security release. (#988045)
  • 6.2.3-1 (to experimental) New upstream security release. (#988045)

Finally, I also made a sponsored upload of adminer (4.7.9-2) for Alexandre Rossi. Debian LTS This month I have worked 18 hours on Debian Long Term Support (LTS) and 12 hours on its sister Extended LTS project.

• Investigated and triaged: apserver (CVE-2021-32062), bundler, djvulibre (CVE-2021-3500), graphviz (CVE-2020-18032), hivex (CVE-2021-3504), libgetdata (CVE-2021-20204), libjs-handlebars (CVE-2021-23383), liblivemedia (CVE-2021-28899), libsixel (CVE-2020-36120), lucene-solor (CVE-2021-27905), opendmarc (CVE-2020-12272), pillow (CVE-2021-25287, CVE-2021-25288, etc.), qemu (CVE-2021-3527), redmine (CVE-2019-25026) and sabnzbdplus (CVE-2021-29488).
• Frontdesk duties, responding to user/developer questions, reviewing others' packages, participating in mailing list discussions, etc.
• Prepared versions of both velocity (1.7-5+deb10u1) and ruby-websocket-extensions (0.1.2-1+deb10u1) to upload to Debian stable to ensure clean upgrades of security-related. I filed two 'unblock requests' for these packages as well (#988455) & #988454).
• Issued DLA 2651-1 and ELA-421-1 for Django, the popular Python-based web development framework. The MultiPartParser, UploadedFile and FieldFile classes allowed directory-traversal via uploaded files with suitably crafted file names. In order to mitigate this risk, stricter path 'basename' and path sanitation is now applied. Specifically, empty file names and paths with dot segments are rejected.
• Issued DLA 2657-1 and ELA-427-1 as it was discovered that there was a potential memory corruption vulnerability in the lz4 compression algorithm library.

You can find out more about the project via the following video:

Debian v11 with codename bullseye is supposed to be released as new stable release soon-ish (let s hope for June, 2021! :)). Similar to what we had with #newinbuster and previous releases, now it s time for #newinbullseye! I was the driving force at several of my customers to be well prepared for bullseye before its freeze, and since then we re on good track there overall. In my opinion, Debian s release team did (and still does) a great job I m very happy about how unblock requests (not only mine but also ones I kept an eye on) were handled so far. As usual with major upgrades, there are some things to be aware of, and hereby I m starting my public notes on bullseye that might be worth also for other folks. My focus is primarily on server systems and looking at things from a sysadmin perspective. Further readings Of course start with taking a look at the official Debian release notes, make sure to especially go through What s new in Debian 11 + Issues to be aware of for bullseye. Chris published notes on upgrading to Debian bullseye, and also anarcat published upgrade notes for bullseye. Package versions As a starting point, let s look at some selected packages and their versions in buster vs. bullseye as of 2021-05-27 (mainly having amd64 in mind):

Package	buster/v10	bullseye/v11
ansible	2.7.7	2.10.8
apache	2.4.38	2.4.46
apt	1.8.2.2	2.2.3
bash	5.0	5.1
ceph	12.2.11	14.2.20
docker	18.09.1	20.10.5
dovecot	2.3.4	2.3.13
dpkg	1.19.7	1.20.9
emacs	26.1	27.1
gcc	8.3.0	10.2.1
git	2.20.1	2.30.2
golang	1.11	1.15
libc	2.28	2.31
linux kernel	4.19	5.10
llvm	7.0	11.0
lxc	3.0.3	4.0.6
mariadb	10.3.27	10.5.10
nginx	1.14.2	1.18.0
nodejs	10.24.0	12.21.0
openjdk	11.0.9.1	11.0.11+9 + 17~19
openssh	7.9p1	8.4p1
openssl	1.1.1d	1.1.1k
perl	5.28.1	5.32.1
php	7.3	7.4+76
postfix	3.4.14	3.5.6
postgres	11	13
puppet	5.5.10	5.5.22
python2	2.7.16	2.7.18
python3	3.7.3	3.9.2
qemu/kvm	3.1	5.2
ruby	2.5.1	2.7+2
rust	1.41.1	1.48.0
samba	4.9.5	4.13.5
systemd	241	247.3
unattended-upgrades	1.11.2	2.8
util-linux	2.33.1	2.36.1
vagrant	2.2.3	2.2.14
vim	8.1.0875	8.2.2434
zsh	5.7.1	5.8

Linux Kernel The bullseye release will ship a Linux kernel based on v5.10 (v5.10.28 as of 2021-05-27, with v5.10.38 pending in unstable/sid), whereas buster shipped kernel 4.19. As usual there are plenty of changes in the kernel area and this might warrant a separate blog entry, but to highlight some issues: One surprising change might be that the scrollback buffer (Shift + PageUp) is gone from the Linux console. Make sure to always use screen/tmux or handle output through a pager of your choice if you need all of it and you re in the console. The kernel provides BTF support (via CONFIG_DEBUG_INFO_BTF, see #973870), which means it s no longer necessary to install LLVM, Clang, etc (requiring >100MB of disk space), see Gregg s excellent blog post regarding the underlying rational. Sadly the libbpf-tools packaging didn t make it into bullseye (#978727), but if you want to use your own self-made Debian packages, my notes might be useful. With kernel version 5.4, SUBDIRS support was removed from kbuild, so if an out-of-tree kernel module (like a *-dkms package) fails to compile on bullseye, make sure to use a recent version of it which uses M= or KBUILD_EXTMOD= instead. Unprivileged user namespaces are enabled by default (see #898446 + #987777), so programs can create more restricted sandboxes without the need to run as root or via a setuid-root helper. If you prefer to keep this feature restricted (or tools like web browsers, WebKitGTK, Flatpak, don t work), use sysctl -w kernel.unprivileged_userns_clone=0 . The /boot/System.map file(s) no longer provide the actual data, you need to switch to the dbg package if you rely on that information:

% cat /boot/System.map-5.10.0-6-amd64 
ffffffffffffffff B The real System.map is in the linux-image-<version>-dbg package

Be aware though, that the *-dbg package requires ~5GB of additional disk space. Systemd systemd v247 made it into bullseye (updated from v241). Same as for the kernel this might warrant a separate blog entry, but to mention some highlights: Systemd in bullseye activates its persistent journal functionality by default (storing its files in /var/log/journal/, see #717388). systemd-timesyncd is no longer part of the systemd binary package itself, but available as standalone package. This allows usage of ntp, chrony, openntpd, without having systemd-timesyncd installed (which prevents race conditions like #889290, which was biting me more than once). journalctl gained new options:

--cursor-file=FILE      Show entries after cursor in FILE and update FILE
--facility=FACILITY...  Show entries with the specified facilities
--image=IMAGE           Operate on files in filesystem image
--namespace=NAMESPACE   Show journal data from specified namespace
--relinquish-var        Stop logging to disk, log to temporary file system
--smart-relinquish-var  Similar, but NOP if log directory is on root mount

systemctl gained new options:

clean UNIT...                       Clean runtime, cache, state, logs or configuration of unit
freeze PATTERN...                   Freeze execution of unit processes
thaw PATTERN...                     Resume execution of a frozen unit
log-level [LEVEL]                   Get/set logging threshold for manager
log-target [TARGET]                 Get/set logging target for manager
service-watchdogs [BOOL]            Get/set service watchdog state
--with-dependencies                 Show unit dependencies with 'status', 'cat', 'list-units', and 'list-unit-files'
 -T --show-transaction              When enqueuing a unit job, show full transaction
 --what=RESOURCES                   Which types of resources to remove
--boot-loader-menu=TIME             Boot into boot loader menu on next boot
--boot-loader-entry=NAME            Boot into a specific boot loader entry on next boot
--timestamp=FORMAT                  Change format of printed timestamps

If you use systemctl edit to adjust overrides, then you ll now also get the existing configuration file listed as comment, which I consider very helpful. The MACAddressPolicy behavior with systemd naming schema v241 changed for virtual devices (I plan to write about this in a separate blog post). There are plenty of new manual pages:

• systemd-bless-boot.8
• systemd-boot-check-no-failures.8
• systemd-boot-system-token.service.8
• systemd-journald-varlink@.socket.8
• systemd.net-naming-scheme.7
• systemd-network-generator.service.8
• systemd-pstore.service.8
• systemd-udev-settle.service.8
• systemd-user-runtime-dir.5
• systemd-xdg-autostart-generator.8

systemd also gained new unit configurations related to security hardening:

• ProtectProc
• ProcSubset
• ProtectClock
• ProtectHostname
• ProtectKernelLogs
• RestrictSUIDSGID

Another new unit configuration is SystemCallLog= , which supports listing the system calls to be logged. This is very useful for for auditing or temporarily when constructing system call filters. The cgroupv2 change is also documented in the release notes, but to explicitly mention it also here, quoting from /usr/share/doc/systemd/NEWS.Debian.gz:

systemd now defaults to the unified cgroup hierarchy (i.e. cgroupv2).
This change reflects the fact that cgroups2 support has matured
substantially in both systemd and in the kernel.
All major container tools nowadays should support cgroupv2.
If you run into problems with cgroupv2, you can switch back to the previous,
hybrid setup by adding systemd.unified_cgroup_hierarchy=false to the
kernel command line.
You can read more about the benefits of cgroupv2 at
https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v2.html

Note that cgroup-tools (lssubsys + lscgroup etc) don t work in cgroup2/unified hierarchy yet (see #959022 for the details). Configuration management puppet s upstream doesn t provide packages for bullseye yet (see PA-3624 + MODULES-11060), and sadly neither v6 nor v7 made it into bullseye, so when using the packages from Debian you re still stuck with v5.5 (also see #950182). ansible is also available, and while it looked like that only version 2.9.16 would make it into bullseye (see #984557 + #986213), actually version 2.10.8 made it into bullseye. chef was removed from Debian and is not available with bullseye (due to trademark issues). Prometheus stack Prometheus server was updated from v2.7.1 to v2.24.1, and the prometheus service by default applies some systemd hardening now. Also all the usual exporters are still there, but bullseye also gained some new ones:

• prometheus-elasticsearch-exporter (v1.1.0)
• prometheus-exporter-exporter (v0.4.0-1)
• prometheus-hacluster-exporter (v1.2.1-1)
• prometheus-homeplug-exporter (v0.3.0-2)
• prometheus-ipmi-exporter (v1.2.0)
• prometheus-libvirt-exporter (v0.2.0-1)
• prometheus-mqtt-exporter (v0.1.4-2)
• prometheus-nginx-vts-exporter (v0.10.3)
• prometheus-postfix-exporter (v0.2.0-3)
• prometheus-redis-exporter (v1.16.0-1)
• prometheus-smokeping-prober (v0.4.1-2)
• prometheus-tplink-plug-exporter (v0.2.0)

Virtualization docker (v20.10.5), ganeti (v3.0.1), libvirt (v7.0.0), lxc (v4.0.6), openstack, qemu/kvm (v5.2), xen (v4.14.1), are all still around, though what s new and noteworthy is that podman version 3.0.1 (tool for managing OCI containers and pods) made it into bullseye. If you re using the docker packages from upstream, be aware that they still don t seem to understand Debian package version handling. The docker* packages will not be automatically considered for upgrade, as 5:20.10.6~3-0~debian-buster is considered newer than 5:20.10.6~3-0~debian-bullseye:

% apt-cache policy docker-ce
  docker-ce:
    Installed: 5:20.10.6~3-0~debian-buster
    Candidate: 5:20.10.6~3-0~debian-buster
    Version table:
   *** 5:20.10.6~3-0~debian-buster 100
          100 /var/lib/dpkg/status
       5:20.10.6~3-0~debian-bullseye 500
          500 https://download.docker.com/linux/debian bullseye/stable amd64 Packages

Vagrant is available in version 2.2.14, the package from upstream works perfectly fine on bullseye as well. If you re relying on VirtualBox, be aware that upstream doesn t provide packages for bullseye yet, but the package from Debian/unstable (v6.1.22 as of 2021-05-27) works fine on bullseye (VirtualBox isn t shipped with stable releases since quite some time due to lack of cooperation from upstream on security support for older releases, see #794466). If you rely on the virtualbox-guest-additions-iso and its shared folders support, you might be glad to hear that v6.1.22 made it into bullseye (see #988783), properly supporting more recent kernel versions like present in bullseye. debuginfod There s a new service debuginfod.debian.net (see debian-devel-announce and Debian Wiki), which makes the debugging experience way smoother. You no longer need to download the debugging Debian packages (*-dbgsym/*-dbg), but instead can fetch them on demand, by exporting the following variables (before invoking gdb or alike):

% export DEBUGINFOD_PROGRESS=1    # for optional download progress reporting
% export DEBUGINFOD_URLS="https://debuginfod.debian.net"

BTW: if you can t rely on debuginfod (for whatever reason), I d like to point your attention towards find-dbgsym-packages from the debian-goodies package. Vim Sadly Vim 8.2 once again makes another change for bad defaults (hello mouse behavior!). When incsearch is set, it also applies to :substitute. This makes it veeeeeeeeeery annoying when running something like :%s/\s\+$// to get rid of trailing whitespace characters, because if there are no matches it jumps to the beginning of the file and then back, sigh. To get the old behavior back, you can use this:

au CmdLineEnter : let s:incs = &incsearch   set noincsearch
au CmdLineLeave : let &incsearch = s:incs

rsync rsync was updated from v3.1.3 to v3.2.3. It provides various checksum enhancements (see option --checksum-choice). We got new capabilities (hardlink-specials, atimes, optional protect-args, stop-at, no crtimes) and the addition of zstd and lz4 compression algorithms. And we got new options:

• --atimes: preserve access (use) times
• --copy-as=USER: specify user (and optionally group) for the copy
• --crtimes/-N: for preserving the file s create time
• --max-alloc=SIZE: change a limit relating to memory allocation
• --mkpath:create the destination s path component
• --open-noatime: avoid changing the atime on opened files
• --stop-after=MINS: stop rsync after MINS minutes have elapsed
• --write-devices: write to devices as files (implies inplace)

OpenSSH OpenSSH was updated from v7.9p1 to 8.4p1, so if you re interested in all the changes, check out the release notes between those version (8.0, 8.1, 8.2, 8.3 + 8.4). Let s highlight some notable new features:

• It now defers creation of ~/.ssh until there s something to write (e.g. the known_hosts file), so the good old admin trick to run ssh localhost and cancel immediately to create ~/.ssh with proper permissions no longer works
• v8.2 brought FIDO/U2F + FIDO2 resident keys Support
• The new include sshd_config keyword allows including additional configuration files via glob(3) patterns
• ssh now allows %n to be expanded in ProxyCommand strings.
• The scp and sftp command-lines now accept -J option as an alias to ProxyJump.
• The scp and sftp command-lines allow the -A flag to explicitly enable agent forwarding.

Misc unsorted

• apt: was updated from version 1.8 to 2.2, apt maintainer Julian Andres Klode wrote something about changes in apt 2.0 and changes in apt 2.2
• e2fsprogs: supports the new ext4 fast_commit feature
• exim: you might be interested being aware of the allow_insecure_tainted_data option, see #987133 + #987924 (Exim 4.94 includes a new tainting-feature)
• glusterfs: was updated from 5.5 to v9.1, there s no direct upgrade path (only v5 towards v8 would be supported), so online migration does not work
• mariadb: no longer runs as /usr/sbin/mysqld, but as /usr/sbin/mariadbd
• python: Python 2.7 (and a few core packages) is still present, but there won t be any security updates for Python 2, see wiki.debian.org/Python/2Removal
• qemu-system-x86: /proc/stat on host does not show guest cpu usage
• rsnapshot is gone (see #986709)

I have just disconnected from irc.freenode.net for the last time. You should do the same. The awful new de facto operators are using user numbers as a public justification for their behaviour. Specifically, I recommend that you:

• Move your own channels to to Libera or OFTC
• If you have previously been known to be generally around on Freenode, connect to Libera (the continuity network set up by the Freenode staff), and register your usual nick(s) there.
• Disconnect from freenode so that you don't count as one of their users.

Note that mentioning libera in the channel topic of your old channels on freenode is likely to get your channel forcibly taken over by the new de facto operators of freenode. They won't tolerate you officially directing people to the competition. I did an investigation and writeup of this situation for the Xen Project. It's a little out of date - it doesn't have the latest horrible behaviours from the new regime - but I think it is worth pasting it here:

Message-ID: <24741.12566.639691.461134@mariner.uk.xensource.com>
From: Ian Jackson <iwj@xenproject.org>
To: xen-devel@lists.xenproject.org
CC: community.manager@xenproject.org
Subject: IRC networks
Date: Wed, 19 May 2021 16:39:02 +0100
Summary:
We have for many years used the Freenode IRC network for real-time
chat about Xen.  Unfortunately, Freenode is undergoing a crisis.
There is a dispute between, on the one hand, Andrew Lee, and on the
other hand, all (or almost all) Freenode volunteer staff.  We must
make a decision.
I have read all the publicly available materials and asked around with
my contacts.  My conclusions:
 * We do not want to continue to use irc.freenode.*.
 * We might want to use libera.chat, but:
 * Our best option is probably to move to OFTC https://www.oftc.net/
Discussion:
Firstly, my starting point.
I have been on IRC since at least 1993.  Currently my main public
networks are OFTC and Freenode.
I do not have any personal involvement with public IRC networks.  Of
the principals in the current Freenode dispute, I have only heard of
one, who is a person I have experience of in a Debian context but have
not worked closely with.
George asked me informally to use my knowledge and contacts to shed
light on the situation.  I decided that, having done my research, I
would report more formally and publicly here rather than just
informally to George.
Historical background:
 * Freenode has had drama before.  In about 2001 OFTC split off from
   Freenode after an argument over governance.  IIRC there was drama
   again in 2006.  Significant proportion of the Free Software world,
   including Debian, now use OFTC.  Debian switched in 2006.
Facts that I'm (now) pretty sure of:
 * Freenode's actual servers run on donated services; that is,
   the hardware is owned by those donating the services, and the
   systems are managed by Freenode volunteers, known as "staff".
 * The freenode domain names are currently registered to a limited
   liability company owned by Andrew Lee (rasengan).
 * At least 10 Freenode staff have quit in protest, writing similar
   resignation letters protesting about Andrew Lee's actions [1].  It
   does not appear that any Andrew Lee has the public support of any
   Freenode staff.
 * Andrew Lee claims that he "owns" Freenode.[2]
 * A large number of channel owners for particular Free Software
   projects who previously used Freenode have said they will switch
   away from Freenode.
Discussion and findings on Freenode:
There is, as might be expected, some murk about who said what to whom
when, what promises were made and/or broken, and so on.  The matter
was also complicated by the leaking earlier this week of draft(s) of
(at least one of) the Freenode staffers' resignation letters.
Andrew Lee has put forward a position statement [2].  A large part of
the thrust of that statement is allegations that the current head of
Freenode staff, tomaw, "forced out" the previous head, christel.  This
allegation is strongly disputed by by all those current (resigning)
Freenode staff I have seen comment.  In any case it does not seem to
be particularly germane; in none of my reading did tomaw seem to be
playing any kind of leading role.  tomaw is not mentioned in the
resignation letters.
Some of the links led to me to logs of discussions on #freenode.  I
read some of these in particular[3].  MB I haven't been able to verify
that these logs have not been tampered with.  Having said that and
taking the logs at face value, I found the rasengan writing there to
be disingenuous and obtuse.
Andrew Lee has been heavily involved in Bitcoin.  Bitcoin is a hive of
scum and villainy, a pyramid scheme, and an environmental disaster,
all rolled into one.  This does not make me think well of Lee.
Additionally, it seems that Andrew Lee has been involved in previous
governance drama involving a different IRC network, Snoonet.
I have come to the very firm conclusion that we should have nothing to
do with Andrew Lee, and avoid using services that he has some
effective control over.
Alternatives:
The departing Freenode staff are setting up a replacement,
"libera.chat".  This is operational but still suffering from teething
problems and of course has a significant load as it deals with an
influx of users on a new setup.
On the staff and trust question: As I say, I haven't heard of any of
the Freenode staff, with one exception.  Unfortunately the one
exception does not inspire confidence in me[4] - although NB that is
only one data point.
On the other hand, Debian has had many many years of drama-free
involvement with OFTC.  OFTC has a formal governance arrangement and
it is associated with Software in the Public Interest.  I notice that
the last few OFTC'[s annual officer elections have been run partly by
Steve McIntyre.  Steve is a friend of mine (and he is a former Debian
Project Leader) and I take his involvement as a good sign.
I recommend that we switch to using OFTC as soon as possible.
Ian.
References:
Starting point for the resigning Freenode staff's side [1]:
  https://gist.github.com/joepie91/df80d8d36cd9d1bde46ba018af497409
Andrew Lee's side [2]:
  https://gist.github.com/realrasengan/88549ec34ee32d01629354e4075d2d48
[3]
https://paste.sr.ht/~ircwright/7e751d2162e4eb27cba25f6f8893c1f38930f7c4
[4] I won't give the name since I don't want to be shitposting.

comments

The freenode IRC network has been hijacked. TL;DR: move to libera.chat or OFTC.net, as did countless free software projects including Gentoo, CentOS, KDE, Wikipedia, FOSDEM, and more. Debian and the Tor project were already on OFTC and are not affected by this.

What is freenode and why should I care? freenode is the largest remaining IRC network. Before this incident, it had close to 80,000 users, which is small in terms of modern internet history -- even small social networks are larger by multiple orders of magnitude -- but is large in IRC history. The IRC network is also extensively used by the free software community, being the default IRC network on many programs, and used by hundreds if not thousands of free software projects. I have been using freenode since at least 2006. This matters if you care about IRC, the internet, open protocols, decentralisation, and, to a certain extent, federation as well. It also touches on who has the right on network resources: the people who "own" it (through money) or the people who make it work (through their labor). I am biased towards open protocols, the internet, federation, and worker power, and this might taint this analysis.

What happened? It's a long story, but basically:

1. back in 2017, the former head of staff sold the freenode.net domain (and its related company) to Andrew Lee, "American entrepreneur, software developer and writer", and, rather weirdly, supposedly "crown prince of Korea" although that part is kind of complex (see House of Yi, Yi Won, and Yi Seok). It should be noted the Korean Empire hasn't existed for over a century at this point (even though its flag, also weirdly, remains)
2. back then, this was only known to the public as this strange PIA and freenode joining forces gimmick. it was suspicious at first, but since the network kept running, no one paid much attention to it. opers of the network were similarly reassured that Lee would have no say in the management of the network
3. this all changed recently when Lee asserted ownership of the freenode.net domain and started meddling in the operations of the network, according to this summary. this part is disputed, but it is corroborated by almost a dozen former staff which collectively resigned from the network in protest, after legal threats, when it was obvious freenode was lost.
4. the departing freenode staff founded a new network, irc.libera.chat, based on the new ircd they were working on with OFTC, solanum
5. meanwhile, bot armies started attacking all IRC networks: both libera and freenode, but also OFTC and unrelated networks like a small one I help operate. those attacks have mostly stopped as of this writing (2021-05-24 17:30UTC)
6. on freenode, however, things are going for the worse: Lee has been accused of taking over a channel, in a grotesque abuse of power; then changing freenode policy to not only justify the abuse, but also remove rules against hateful speech, effectively allowing nazis on the network (update: the change was reverted, but not by Lee)

Update: even though the policy change was reverted, the actual conversations allowed on freenode have already degenerated into toxic garbage. There are also massive channel takeovers (presumably over 700), mostly on channels that were redirecting to libera, but also channels that were still live. Channels that were taken over include #fosdem, #wikipedia, #haskell... Instead of working on the network, the new "so-called freenode" staff is spending effort writing bots and patches to basically automate taking over channels. I run an IRC network and this bot is obviously not standard "services" stuff... This is just grotesque. At this point I agree with this HN comment:

We should stop implicitly legitimizing Andrew Lee's power grab by referring to his dominion as "Freenode". Freenode is a quarter-century-old community that has changed its name to libera.chat; the thing being referred to here as "Freenode" is something else that has illegitimately acquired control of Freenode's old servers and user database, causing enormous inconvenience to the real Freenode.

I don't agree with the suggested name there, let's instead call it "so called freenode" as suggested later in the thread.

What now? I recommend people and organisations move away from freenode as soon as possible. This is a major change: documentation needs to be fixed, and the migration needs to be coordinated. But I do not believe we can trust the new freenode "owners" to operate the network reliably and in good faith. It's also important to use the current momentum to build a critical mass elsewhere so that people don't end up on freenode again by default and find an even more toxic community than your typical run-of-the-mill free software project (which is already not a high bar to meet). Update: people are moving to libera in droves. It's now reaching 18,000 users, which is bigger than OFTC and getting close to the largest, traditionnal, IRC networks (EFnet, Undernet, IRCnet are in the 10-20k users range). so-called freenode is still larger, currently clocking 68,000 users, but that's a huge drop from the previous count which was 78,000 before the exodus began. We're even starting to see the effects of the migration on netsplit.de. Update 2: the isfreenodedeadyet.com site is updated more frequently than netsplit and shows tons more information. It shows 25k online users for libera and 61k for so-called freenode (down from ~78k), and the trend doesn't seem to be stopping for so-called freenode. There's also a list of 400+ channels that have moved out. Keep in mind that such migrations take effect over long periods of time.

Where do I move to? The first thing you should do is to figure out which tool to use for interactive user support. There are multiple alternatives, of course -- this is the internet after all -- but here is a short list of suggestions, in preferred priority order:

1. irc.libera.chat
2. irc.OFTC.net
3. Matrix.org, which bridges with OFTC and (hopefully soon) with libera as well, modern IRC alternative
4. XMPP/Jabber also still exists, if you're into that kind of stuff, but I don't think the "chat room" story is great there, at least not as good as Matrix

Basically, the decision tree is this:

• if you want to stay on IRC:
  • if you are already on many OFTC channels and few freenode channels: move to OFTC
  • if you are more inclined to support the previous freenode staff: move to libera
  • if you care about matrix users (in the short term): move to OFTC
• if you are ready to leave IRC:
  • if you want the latest and greatest: move to Matrix
  • if you like XML and already use XMPP: move to XMPP

Frankly, at this point, everyone should seriously consider moving to Matrix. The user story is great, the web is a first class user, it supports E2EE (although XMPP as well), and has a lot of momentum behind it. It even bridges with IRC well (which is not the case for XMPP) so if you're worried about problems like this happening again. (Indeed, I wouldn't be surprised if similar drama happens on OFTC or libera in the future. The history of IRC is full of such epic controversies, takeovers, sabotage, attacks, technical flamewars, and other silly things. I am not sure, but I suspect a federated model like Matrix might be more resilient to conflicts like this one.) Changing protocols might mean losing a bunch of users however: not everyone is ready to move to Matrix, for example. Graybeards like me have been using irssi for years, if not decades, and would take quite a bit of convincing to move elsewhere. I have mostly kept my channels on IRC, and moved either to OFTC or libera. In retrospect, I think I might have moved everything to OFTC if I would have thought about it more, because almost all of my channels are there. But I kind of expect a lot of the freenode community to move to libera, so I am keeping a socket open there anyways.

How do I move? The first thing you should do is to update documentation, websites, and source code to stop pointing at freenode altogether. This is what I did for feed2exec, for example. You need to let people know in the current channel as well, and possibly shutdown the channel on freenode. Since my channels are either small or empty, I took the radical approach of:

• redirecting the channel to ##unavailable which is historically the way we show channels have moved to another network
• make the channel invite-only (which effectively enforces the redirection)
• kicking everyone out of the channel
• kickban people who rejoin
• set the topic to announce the change

In IRC speak, the following commands should do all this:

/msg ChanServ set #anarcat mlock +if ##unavailable
/msg ChanServ clear #anarcat users moving to irc.libera.chat
/msg ChanServ set #anarcat restricted on
/topic #anarcat this channel has moved to irc.libera.chat

If the channel is not registered, the following might work

/mode #anarcat +if ##unavailable

Then you can leave freenode altogether:

/disconnect Freenode unacceptable hijack, policy changes and takeovers. so long and thanks for all the fish.

Keep in mind that some people have been unable to setup such redirections, because the new freenode staff have taken over their channel, in which case you're out of luck... Some people have expressed concern about their private data hosted at freenode as well. If you care about this, you can always talk to NickServ and DROP your nick. Be warned, however, that this assumes good faith of the network operators, which, at this point, is kind of futile. I would assume any data you have registered on there (typically: your NickServ password and email address) to be compromised and leaked. If your password is used elsewhere (tsk, tsk), change it everywhere. Update: there's also another procedure, similar to the above, but with a different approach. Keep in mind that so-called freenode staff are actively hijacking channels for the mere act of mentioning libera in the channel topic, so thread carefully there.

Last words This is a sad time for IRC in general, and freenode in particular. It's a real shame that the previous freenode staff have been kicked out, and it's especially horrible that if the new policies of the network are basically making the network open to nazis. I wish things would have gone out differently: now we have yet another fork in the IRC history. While it's not the first time freenode changes name (it was called OPN before), now the old freenode is still around and this will bring much confusion to the world, especially since the new freenode staff is still claiming to support FOSS. I understand there are many sides to this story, and some people were deeply hurt by all this. But for me, it's completely unacceptable to keep pushing your staff so hard that they basically all (except one?) resign in protest. For me, that's leadership failure at the utmost, and a complete disgrace. And of course, I can't in good conscience support or join a network that allows hate speech. Regardless of the fate of whatever we'll call what's left of freenode, maybe it's time for this old IRC thing to die already. It's still a sad day in internet history, but then again, maybe IRC will never die...

Today marks the 90th day of me joining Canonical to work on Ubuntu full-time! So since it s been a while already, this blog post is long due. :)

The News

I joined Canonical, this February, to work on Ubuntu full-time! \o/
Those who know, they know that this is really very exciting for me because Canonical has been a dream company for me, for real (more about this below!). And hey, this is my first job, ever, so all the more reason to be psyched about, isn t it? ^_^ P.S. Keep reading and we ll meet my squad really sooon!

The Story Being an undergrad student (batch 2017-2021), I ve been slightly worried during my last two semesters, naturally, thinking about how s it all gonna pan out and what will I be doing, et al, because I ve been seeing all my friends and batchmates getting placed in companies or going for masters or at least having some sort of plans for their future and I, on the other hand, was hopelessly clueless. :D Well, to be fair, I did Google Summer of Code twice, in 2019 and 2020, became a Debian Developer in 2019, been a part of GCI and Outreachy, contributed to over dozens of open-source projects, et al, et al. So I wasn t all completely hopeless but for sure was completely clueless , heh. And for full disclosure, I was only slightly panicking because firstly, I did get placed in several companies and secondly, I didn t really need a job immediately since I was already getting paid to work on Debian stuff by Freexian, which was good enough. :)
(and honestly, Freexian has my whole heart! - more on that later sometime.) But that s not the point. I was still confused and worried and my mom & dad, more so than anyone. Ugh. We were all figuring out and she asked me places that I was interested to work in. And whilst I wasn t clear about things I wanted to do (and still am!) but I was (very) clear about this and so I told her about Canonical and also did tell her that it s a bit too ambitious for me to think about it now so I ll probably apply after some experience or something. and as they say, the world works in mysterious ways and well, it did for me! So back during the Ruby sprints (Feb 20), Kanashiro, the guy ( ), mentioned that his team was hiring and has a vacant position but I won t be eligible since I was still in my junior year. It was since then I ve been actively praying for Cronus, the god of time, to wave his magic wand and align it in such a way that the next opening should be somewhere near my graduation. And guess what? IT HAPPENED! 9 months later, in November 20, Kanashiro told me his team is hiring yet again and that I could apply this time! Without much (since there was some ) delay, I applied and started asking all sorts of questions to Kanashiro. No words are enough for him, he literally helped me throughout the process; from referring me to answering all sorts of doubts I had! And roughly after 2 months of interviewing, et al, my ambitious dream did come true and I finalyyyy signed my contract! \o/
(the interview process and what went on during those 10 weeks is a story for later ;))

The Server Team! \o This position, which I didn t mention earlier, was for the Server Team which is a team of 15 people, working to make Ubuntu server the best! And as I tweeted sometime back, the team is absolutely lovely, super kind, and consists of the best of teammates one could possibly ask for! Here s a quick sneak peek into our weekly team meeting. Thanks to Rafael for taking such a lovely picture. And yes, the cat Luna is a part of our squad! And oh, did I mention that we re completely remote and distributed?
FUN FACT: Our team covers all the TZs, that is, at any point of time (during weekdays), you ll find someone or the other from the team around! \o/ Anyway, our squad, managed by Rick is divided into two halves: Squeaky Wheels and Table Flip. Cool names, right?
Squeaky Wheels does the distro side of stuff and consists of Christian, Andreas, Rafael, Robie, Bryce, Sergio, Kanashiro, Athos, and now myself as well! And OTOH, Table Flip consists of Dan, Chad, Paride, Lucas, James, and Grant. Even though I interact w/ Squeaky Wheels more (basically daily), each of my teammates is absolutely lovely and equally awesome! Whilst I ll talk more about things here in the upcoming months, this is it for now! If there s anything, in particular, you d like to know more about, let me know! And lastly, here s us vibing our way through, making Ubuntu server better, cause that s how we roll!

---

Until next time.
:wq for today.

So we're a fair way through the release, then. Testing of almost all the standard images has finished. Pretty much all of the disk images are now complete and in place.People are working their way through the tests of the debian-live images in the various desktop flavours. These have to be done on real hardware - so it does take time. A new tester - peylight - has dropped in to help for the first time. Sqrt not has also joined us from the other end of the timezone scale - we have somebody at UTC-0700 and somebody at UTC+0430 today. [I can't remember where Linux-fan is timezone wise] All of the help from all the testers is very welcome, as ever.
A slight pause - a couple of us have a meal to eat - but it looks as if we've done well on timings. The original estimate was for 2000UTC - maybe a little after that and we'll be finished and the images release can be published - there were a couple of minor hiccups but we've done well so far.
Thanks, as always, to the people behind the scenes doing all the work, to DSA and admins providing large machines for us to do the builds on and to the people who drop in and spend a few hours of their time on a working day/weekend to help out.

We're almost there: last lots of AMD64 testing on the debian-live images - a couple of willing helpers are also testing some i386 images though these can be more problematic on low memory. Steve has just started the final stage to start the final scripts. If all goes well, they should be done within 3/4 of an hour - which should put the images in the final locations on the main mirror by about 2230 UTC. It's been something of the order of twelve hours from start to finish which is still slightly quicker than most of the releases we've done - as ever, thanks to all. And that's it for another however long until we get to sort out 10.10 in a while.

And so I'm rather late: Sledge, RattusRattus and Isy and I have all been busy chasing down bits and pieces for images release today. We're well underway through the normal images: live images are still ongoing. We've had help from Schweer and Linux-fan as last time - a couple of other folk have had chats to us. So far, it seems relatively straightforward - we're all experienced at this by now.As ever, it's a joy to be doing this with a smart set of colleagues. We can now catch our mistakes _just_ after we make them, so it's really getting sorted: the next stage is for me to realise _before_ I make them.

Here is my monthly update covering what I have been doing in the free software world during February 2021 (previous month):

• Reviewed and merged a number of contribution from Peter Law to my django-cache-toolbox library for Django-based web applications, including: support always fetching some relations when loading a model (#27), allow use of custom auth.User model. (#29), avoid some more database calls (#30), wrap some collections in tuples for compatibility (#32) and cope with only some of our related models actually being loaded (#33).

• As part of my role of being the assistant Secretary of the Open Source Initiative and a board director of Software in the Public Interest, I attended their respective monthly meetings and participated in various licensing and other discussions occurring on the internet, as well as the usual internal discussions, etc.
• Opened a pull request to fix the relative target of manpage links in Roger Wesson's mocassin library. [...]

Reproducible Builds The motivation behind the Reproducible Builds effort is to ensure no flaws have been introduced during compilation process by promising identical results are always generated from a given source, therefore allowing multiple third-parties to come to a consensus on whether a build was compromised. The project is proud to be a member project of the Software Freedom Conservancy. Conservancy acts as a corporate umbrella allowing projects to operate as non-profit initiatives without managing their own corporate structure. If you like the work of the Conservancy or the Reproducible Builds project, please consider becoming an official supporter. This month, I:

• Filed an upstream pull request to fix relative symlink targets of manpage links in mocassin. [...]
• In Debian:
  • Submitted 5 patches to fix specific reproducibility issues in crossfire, golang-github-revel-revel, golang-github-viant-toolbox, python-aiosqlite & zmk.
  • Kept isdebianreproducibleyet.com up to date. [...]
  • Submitted a patch to fix reproducibility-related toolchain issue in kjs: Please make the opcodes.h file reproducible. (#983046)
• Categorised a large number of packages and issues in the Reproducible Builds notes.git repository as well as wrote a script to automatically-classify a number of issues [...].
• Drafted, published and publicised our monthly report for January.

I also made the following changes to diffoscope, including preparing and uploading versions 167 and 168 to Debian:

• Bug fixes:
  • Don't call difflib.Differ.compare with very large inputs; it is at least O(n^2) and makes diffoscope (appear to) hang. [...]
  • Don't rely on dumpimage returning an appropriate exit code; check that the file actually exists. [...]
  • Don't rely on magic.Magic to have an identical API between file's magic.py and PyPI's python-magic library. [...]
• Revamp temporary file handling:
  • Ensure we cleanup our temporary directory by avoiding confusion between the TemporaryDirectory instance and underlying directory. (#981123)
  • Try and use a potentially-useful suffix to our temporary directory. [...]
• Testsuite improvements:
  • Strip newlines when determining Black version to avoid requires black >= 20.8b1 (18.9b0\n detected) in test output. [...]
  • Fix weakref-related handling in Python 3.7 (i.e. Debian buster). [...]
  • If our temporary directory does not exist anymore, recreate it. [...]
  • Fix FIT-related tests in Debian buster [...] and fit_expected_diff [...].
  • Gnumeric is back in testing so re-add to (test) Build-Depends. [...]
  • Mark test_apk.py::test_android_manifest as being allowed to fail for now. [...]
  • Add u-boot-tools to (test) Build-Depends so salsa.debian.org pipelines test the new U-Boot FIT comparator. [...]
  • Move to assert_diff utility in a number of tests. [...][...]
• Codebase improvements:
  • Correct capitalisation of 'jQuery'. [...]
  • Update my copyright years. [...]
  • Tidy imports in diffoscope.comparators.fit. [...]
  • Don't use Inheriting PATH of X, use PATH is X in logging messages. [...]
  • Drop unused Config.acl and Config.xattr attributes [...] and set a default Config.extended_filesystem_attributes. [...]

Debian Uploads

• python-django:
  • 2.2.18-1 New upstream security release. (#981562)
  • 2.2.19-1 New upstream security release. (#983090)
  • 3.2~alpha1-2 Apply security fix from upstream. (#983090)
  • 3.2~beta1-1 New upstream beta release.
• redis:
  • 6.0.10-4 New upstream release, fixing cluster access to unaligned memory on ARM architectures with hard alignment requirements (such as armhf and arm64). (#982504)
  • 6.0.11-1 New upstream release, incorporating security fixes. (#983446)
  • 6.2~rc3-1 New upstream release candidate.
  • 6.2.0-1 New upstream stable release, incorporating security fixes. (#983446)
• gunicorn (20.1.0-1) New upstream release.
• xtrlock (2.15) Also support the XK_KP_Enter key (i.e. the Enter on the numeric keypad) to submit a password. (#982634)

I also sponsored an upload of adminer (4.7.9-1) for Alexandre Rossi. Debian LTS This month I have worked 18 hours on Debian Long Term Support (LTS) and 12 hours on its sister Extended LTS project.

• Frontdesk duties, responding to user/developer questions, reviewing others' packages, participating in mailing list discussions, and attending our monthly development meeting. etc.
• Updated the lts-cve-triage.py tool to configure Python paths early due to transitive imports in an included library. [...]
• Investigated and triaged: avahi (CVE-2021-26720), gdk-pixbuf (CVE-2021-20240), libraw (CVE-2020-24870), python3.5 (CVE-2021-3177), qemu (CVE-2020-15469, CVE-2020-15859, CVE-2020-25084 etc.), rails (CVE-2021-22880 & CVE-2021-22881), stunnel4 (CVE-2021-20230 & CVE-2021-20231) & zeromq3 (CVE-2021-20237)
• Issued DLA 2555-1 for netty as it was discovered that there was an insecure temporary file issue that could have lead to disclosure of arbitrary local files.
• Issued DLA 2562-1 to address a remote code execution vulnerability in mumble, a VoIP client commonly used for group chats. The exploit could have been been triggered by a maliciously crafted URL on the server list.
• Issued DLA 2563-1, DLA 2565-1 and ELA-366-1 for openssl to prevent an issue where "Digital EnVeloPe" EVP-related calls could cause applications to behave incorrectly or even crash (CVE-2021-23840) and address to an issue in the X.509 certificate parsing caused by the lack of error handling while ingesting the 'issuer' field.
• Issued DLA 2568-1 and ELA-369-1 as it was discovered that there was a buffer overflow attack in the bind9 DNS server, caused by an issue in the GSSAPI ("Generic Security Services") security policy negotiation.
• Issued DLA 2540-1, DLA 2569-1 and ELA-354-1 for python-django to address a potential directory-traversal (CVE-2021-3281) and a cache-poisoning issue (CVE-2021-23336).
• Issued DLA 2576-1 for redis as it was reported that there were a number of integer overflow.

You can find out more about the project via the following video: